home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0337.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  3.4 KB  |  69 lines
  1.  
  2. >  Date:       Fri, 13 Nov 92 09:42:56 GMT
  3. >  From: "KHOADLEY" (KHOADLEY at UKACRL)        <KHOADLEY@ib.rl.ac.uk>
  4. ...
  5. >  There seems little reason to me for the ISINDEX tag. Searching consists of
  6. >  two components: the client constructing a list of queries designed to
  7. >  retrieve the relevant information, and the server receving and processing
  8. >  those queries. Once you start to consider a single user initiated search
  9. >  generated multiple queries there seems to be little point in tieing searches
  10. >  down to particular tagged documents.
  11. >  (of course once a search generates multiple queries it can receive multiple
  12. >  replies. AS these replies could come from different servers it becomes the
  13. >  responsibility of the client end to aggregate the replies into something
  14. >  useful to return to the user: a selection panel for instance).
  15.  
  16. Every seach needs to search SOMETHING.  Like it has to search a particular  
  17. database or index.  Some servers support thousands of "virtual" indexes. How  
  18. can you express this in a search? The answer is that indexes are names just  
  19. like documents. we then have a convention that if you try to retrieve an index  
  20. as a document, you get back a description of it. This latter is something  
  21. missing for example from WAIS where you have to look up the SOURCE file for a  
  22. database in a totally differents server which may be out of sync (and, being  
  23. centralized, doesn't scale).
  24.  
  25. If you regard a query as something which is just thrown at the server, then you  
  26. can't allow a ruch enough world of virtual search servers. This was a problem  
  27. with the gopher protocol which causes the Gopher guys to make a  
  28. non-back-compatible sudden change in the protocol spec to introduce an index  
  29. name. 
  30.  
  31.  
  32. >  I'd like to see the ISINDEX tag dropped: the client is free to construct
  33. >  whatever queries they wish, using the existing HTTP query mechanism.
  34. >  
  35.  
  36. >  Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
  37. >  used for purposes other than searching, eg. for "smart" documents or
  38. >  to calculate square roots ! (an example familiar to those at the HEPix
  39. >  meeting ...). However using a tag that appears to have been intended for
  40. >  search purpose for something different is confusing to the end user: ie
  41. >  the page asks for the value you wish to square root, whilst the client
  42. >  prompts you for a string to search for ....
  43. >  
  44.  
  45. >  Perhaps the following could be useful:
  46. >             <INPUT VAR=x>Please enter your name</INPUT>
  47. >             <DONEINPUT>
  48. >  ie a series of input fields with associated labels, and a button to say
  49. >  you have finished and now send the query. This opens the possibility
  50. >  of forms based pages generating smart documents. How you send the input is
  51. >  a different matter; maybe:
  52. >      http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz
  53.  
  54. This is the tip of the iceberg.  I think the onlywy to do it generally is (see  
  55. my previous message) to have typed queries, and generic editors for them.
  56. The case above would become something like
  57. <ISINDEX TYPE="iana:/www/classes/query/personalinfo">
  58. The type would also be retrievable like a document, and if you had a generic
  59. query language language, you would get back a description of the query language  
  60. supported. A generic client could use that to generate the form to be filled in  
  61. by a user.
  62.  
  63. >  Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk
  64. >  
  65.  
  66.  
  67. Tim Berners-Lee
  68.  
  69.